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PERT for the engineer 

Engineers may associate PERT with large military programs 
and computers, but they should know that PERT can also be 
applied effectively to modest engineering tasks 

Jordan Kadet, Bruce H. Frank Sylvania Electric Products Inc. 


Although PERT (Program Evaluation and Review 
Technique) was successfully introduced in 1958 on the 
Polaris Weapons System Program and subsequently it 
and similar networking techniques were enthusiastically 
accepted in the management of the development phase 
of weapons systems programs, as well as within industries 
such as construction, we now observe a curious phe- 
nomenon. Many engineers, employed as project engineers 
either by large corporations on major programs or by 
small laboratories engaged in component or subsystem 
development, still question the effectiveness of PERT 
for their own use. Much of the cynicism that greets the 
technique can be traced, in part, to a lack of conviction 
on the part of engineers that PERT can be an effective 
planning and control technique for modest task appli- 
cations as well as for large programs necessitating elab- 
orate, computer-based applications. 

When should PERT be used? 

This article is directed at the individual engineer or 
project engineer engaged in tin engineering task or small 
project, whether oriented toward defense or commercial 
products. The size of the task docs not affect the require- 
ment for planning nor need it influence the decision to 
use PERT techniques. PERT techniques for planning and 
control, involving graphic methods and network analysis 
to depict and analyze a project, can be applied to 
large or small projects, formally or informally. The nature 
of the project does, however, influence this decision. The 
networking technique is applicable primarily to the 
"once-through” typo of effort typically associated with the 
development of a system or subsystem, that is, one where 

n The objective of the effort is to realize an engineering 
model or prototype model of a hitherto nonexistent 
item or items of equipment. 


■ The achievement of the objective involves some degree 
of uncertainty because of the lack of directly applicable 
experience on which to base estimates, 
a The achievement of the objec tive is subject to significant 
changes in direction, intensity, and scope as the work 
progresses. 

Efforts of a repetitive nature and predictable course, 
such as volume production, runs, are normally better 
planned and managed thre 1 :, :h the use of other tech- 
niques/for example, Line-of-Balance). There is, however, 
no clear cutoff point between the once-through process 
and the repetitive process when development programs 
include the production of initial or limited quantities of 
end items. 

Basic research programs and endeavors aimed at 
breakthroughs in the state-of-the-art are less amenable 
to PERT even though they, too, are normally once- 
through processes. PERT becomes less meaningful when 
objectives cannot be clearly defined. 

Within these limits, networking may be successfully 
applied. This does not imply that PERT and other net- 
working techniques such as CPM (Critical Path Method) 
apply only to developmental engineering tasks. The ap- 
plications are as varied as industry itself. These tech- 
niques have been applied and found useful in the follow- 
ing areas: 

Government research and development 

Commercial product development 

Installation of equipment 

Construction 

First production runs 

Maintenance 

Systems and procedures installation 

Training programs 

Movie and stage productions 
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Military electronics, at one time the predominant usei 
of PERT techniques, can no longer make this claim. 
Booz Allen and Hamilton, Management Consultants, 
reported that, “By 1963, 85 per cent of the companies 
surveyed were using PERT either exclusively or partially 
for private commercial work.” 1 Although diverse applica- 
tions have bred many variations of the techniques, 
the basic concepts have not changed. 

What PERT is and is not 

Before PERT methods of planning and control are dis- 
cussed, several myths shrouding these techniques must be 
dispelled. Conventional, nonprobabilistic, bar chart plan- 
ning led to the popular belief, reinforced by many engi- 
neers, that research and development work cannot aptly 
be measured in terms of time and cost progress. You 
can’t schedule invention,” “You can’t expect us to de- 
sign by the calendar,” “Mental processes can’t be 
planned” are frequent statements heard. PERT, with 
a probabilistic approach to time planning, has helped to 

dispel this myth. . 

Whenever a new technique such as PERT is developed, 
it tends to introduce a new breed of specialist, and a new 
language is promulgated which is understood, presuma- 
bly, only by the “privileged few.” When discussing 
their work, PERT specialists (“PERTniks”) use terms 
such as slack, critical path, expected time, latest allow- 
able time, and a host of others. Because PERT specialists 
in staff and line positions are needed for large-scale PERT 
applications, some people are led to believe that PERT 
is a mystical system, complicated to use and one which 
will not prove durable. In practice, however, 1 ERT is 
surviving, and the techniques do not necessarily require 
specialist personnel for intelligent application. It has 
been suggested by some writers 2 that a PERT analysis 
stall be eliminated and that project engineers perform 


this function. The suggestion has merit and certainly is 
correct in its implication that the engineer or project 
engineer plays a key role in a successful PERT system. 

The reason that PERT applications continue to expand 
is that the technique provides many advantages. Among 
these are 

n A disciplined approach to planning, 
a A method of visualizing the work and of com- 
municating plans. 

r A plan which can reflect uncertainties but which can 
also be easily used for calculating the time to perform the 
project. 

■ A means for appraising progress and forecasting, 
problem areas. 

The subsequent sections define the steps that should 
be followed in planning a project, large or small, and 
the networking techniques that should be applied. 
Many of these techniques are not unique to networking 
but have been in use for a long time. This is why we refer 
to PERT as being both evolutionary and revolutionary. 

Before delving into the how and why of PERT, let us 
define what it is. PERT is a planning and control dis- 
cipline which employs a specific set of principles, meth- 
ods, and techniques for effective planning. The key ele- 
ments of this discipline are 

r A work breakdown structure, which begins with the 
objectives and subdivides them into successively smaller 
elements of work. 

■ A network , comprising all the work which must be 
accomplished to reach the objectives, and depicting the 
planned sequence of accomplishment of this work as 
well as the interdependencies and interrelationships. 

h Elapsed time estimates of work to be performed and 
schedule* Which also consider the availability of resources. 


Fig. 1. Typical engineering equipment breakdown or “family tree." 
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9 : Analysis of the interrelated networks and schedules 
ns a basis for continued evaluation of performance and 
idem mca lion ot problem oxccis. 

PERT is also a discipline for organizing data, docu- 
menting the plan, and manipulating the plan to elfcct 
a successful conclusion to the project. The statement that 
PERT is a discipline and a tool for planning and control- 
ling a job is significant to an understanding of the tech- 
nique. Although the technique is formalized it is no 
different from what any of us must ordinarily do to 
plan and control our work properly. As will be seen, 
elements of this technique had their origin in engineering 
applications. It must be remembered that PERT is not a 
panacea or substitute for the decision-making process; 
it is only a tool to aid the decision makers. 

Defining the job 

Before any project or task, large or small, can be under- 
taken it must be defined. The engineer must define the 
objectives in terms such as final hardware. The hardware, 
perhaps, can be broken down into various levels such as 
assemblies, subassemblies, and components. This ex- 
ercise is generally expressed on paper by the preparation 
of a “family tree” or “Christmas tree” equipment break- 
down. This breakdown, dividing the piece or pieces suc- 
cessively into component parts (see Fig. 1), is the “road 
map” for the designer or project engineer. In any project 
there may be other end-item requirements such as engi- 
neering data and ancillary items. It is possible and prac- 
tical to expand the family tree to include these items. The 
expanded family tree that evolves is known in the 
language of PERT as a work breakdown structure. The 


work breakdown structure does not stop at the level of 
end-item hardware, data, and services. As can be seen 
in Fig. 2, the breakdown continues to a definition of the 
required tasks such as design, fabrication, and test of 
each piece of hardware. 

The resultant work tasks or work packages are likely 
to be assigned as separate responsibilities to organiza- 
tions or individuals and are thus defined separately. 
As the family tree provided a road map for designing, 
so the work breakdown structure provides a road map 
for planning. The work breakdown structure establishes 
the basis for 

g Defining and relating the work to be performed and 
the program objectives. 

a Identifying the responsibility for accomplishment 
of the work packages and monitoring at higher levels. 

a Detailed PERT planning and control. 

■ Cost planning and control. 

In a project, the work packages must be defined in 
detail. This is usually done either by simple written de- 
scriptions on a small project, or on a larger, complex 
program by more formal task authorizations. These 
should define the specifications, performance parameters, 
and the budget and schedule for the work packages. 
While these define the work in terms the engineer can 
understand, the plan for performance of this work re- 
mains to be prepared. 

Network planning 

Network planning or PERT was developed primarily 
to fill the need for a tool that would allow the engineer 
to depict what really was going to happen in his relatively 


Fig. 2. In PERT language, this is a work breakdown structure; 
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complex R&D task or project. The Gantt or milestone 
charts which were in use for planning had been adapted 
from production planning methods and were found 
wanting. Networking techniques were derived from 
those used in electrical engineering and from flow charting 
used in computer programming. Networking is a logical 
discipline for planning a task. It is not the network which 
is prepared ; it is the plan which is prepared using network 
discipline. This distinction is basic for an appreciation oi 
networking as a planning and control tool for the engi- 
neer. . 

The discipline of planning can be defined by a series or 

questions which must be answered: 

■s What work must be performed? 

b What is needed to perform this work ? 

0 How will completion be identified ? 


Test procedures \ 
ssued for L. 

approval oy j 

project manager J 

Event 


Ap prove test procedures 
Activity 



Test procedures 
approved 


Event 


Fig. 3. Basic elements of a PERT network are events and 
activities. 


Fig. 4. Network relationships: serial activities (A), an ac- 
tivity dependent upon parallel activities (B), and parallel 
activities dependent upon one restraining activity (C). 
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These questions can only be answered accumiely by 
the responsible engineer or project engineer. When he 
thinks of his task in terms of these questions, he can plan 
in detail using a network approach. Once he has delineated 
the work and its sequence in detail, he may considei 
another very important question: 

■ How long will it take to perform the work ? 

The basic advantage of planning by this discipline is 
that it requires the engineer to think of his work in its en- 
tirety and to consider all of the individual parts. 

Simply, a PERT network or chart is made up of two 
elements:’ events and activities. Activities are the work to 
be performed and are signified by arrows. Events aie 
specific definable achievements— either the beginning or 
completion of one or more activities — and are represented 
on the network by circles, ellipses, rectangles, or other 
geometric figures. Every activity is bounded by an event 
at the beginning and an event at the end (see Fig. 3). 

The method of preparing a network simply involves 
connecting activities and events to show their relation- 
ship. If one activity cannot be performed until another 
has been completed, it should be drawn as shown in Fig. 
4(A). If, on the other hand, the activity cannot start until 
more than one activity is complete, it should be drawn as 

in Fig. 4(B). . 

Another type of network interrelationship exists in 
which nlqre than one activity may start when a single 
previous ’‘activity has been completed. This type of con- 
straint cud parallel start is shown in Fig. 4(C). It is 
important id remember that the network represents 
logical;',:.--: amts, not time sequencing. The network shows 
whicli ; :.c (.vibes must be accomplished before another 
may It 'should not be drawn to show all activities 
that 'pay, because of preconceived ideas, be occurring 
prior 1 tu another in time only. If the activity can be per- 
'ormoq regardless of the status of other activities, no con- 
strain. should be shown. Figure 5 shows an example ot 

an abbreviated network. _ , 

Ouse V)i: above principles of networking are undei- 
stood, rfiiay other questions regarding rules of prepara- 
tion are raised. One of the first is: How do we prepare 
it— do we start at the beginning and work toward the end 
or do we start at the end and work toward the begin- 
n j ng _ w hat is the “standard” method? Although some 
articles in the past have extolled the virtues of one or the 
other method, we have found that there is no “ standard ” 
method. One can start at the front, back, or even in the 
middle, in preparing a network; it depends on the indi- 
vidual or group planning the job. If, as is trequently possi- 
ble, a more effective plan can be developed by working 
from the end towards the beginning, then the network 
should be drawn accordingly. If you prefer, start at the 
beginning; once the network is prepared, however, it 
must represent the complete plan for accomplishing tire 
job. 

Another frequently asked question is: How large is a 
good network? A quick answer might be: Large enough 
to be a complete plan of the work to be performed. This 
answer only provokes another request for some guidelines 
for measurement. We have seen networks with thousands 
of activities (on a major weapons systems program) and 
with as few as 20 to 25 (on a small task). These were 
both good for their uses. Conversely, very small networks 
have been developed for very large projects and some 
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T e = 0 + 2 = 2 



Fig. 5. Example of a PERT network structure, where t„ is statistically expected time of activity, 
Tj. : is earliest expected date, Tx, is latest allowable date, and dashed line is critical path. 


very large networks developed for small projects, none of 
which constituted a good plan. The basic problem with 
these networks was that preconceived artificial limits were 
set on network size. Such limits — “no fewer than 150 activ- 
ities,” “no greater than 100 activities,” “on a sheet of paper 
no larger than one foot by two feet” — are usually artificial 
and should be avoided whenever possible. The first rule is 
to prepare the network without regard for size or neatness 
and then, when it is complete, worry about the size limita- 
tions that may be imposed. As a rule of thumb, with full 
regard to the differences in projects in their scope, techni- 
cal sophistication, and duration, we have found that 
there should be an average elapsed time for the majority 
of the activities approximately equal to the period be- 
tween progress reviews. As an example, if the network is 
reviewed weekly (as might be the case in a small engi- 
neering job), the activities should average 1-1 Vi weeks. 
If the network is reviewed monthly, the average 
should be 3-4 weeks. Although this is not a hard and 
fast rule, we have found it to hold true in most cases. 
This may seem to contradict our comment that the net- 
work should be prepared first and the duration estimated 
second, bul network size is not really checked until time 


Definitions 

Optimistic time (a) = The time the activity will 
take if everything to be done is done successfully 
the first time. 

Most likely time (»;) = The time required to 
accomplish an activity under norma! circumstances 
with some success and some failure. 

Pessimistic time (b) = The time the activity 
will take with extremely bad luck. 


estimating is completed! This procedure is not illogical 
for it has been found that many networks undergo major 
modifications and improvements as time estimates are 
made. ,: j 

Time estimating 

Once the network has been developed, portraying the 
relationships and interdependencies among the activities, 
the time needed for each activity should be estimated. 
This should be done by the engineers who are going to do 
the work. 

There are two basic met ods of time estimating, proba- 
bilistic and deterministic, and the use of one or the other 
is optional. 

Probabilistic time estimating, which was developed as 
part of the PERT system, requires three estimates for the 
duration of an activity (see Definitions). These three esti- 
mates are plotted on a beta distribution to find sta- 
tistically expected time 1 e . = (« + 4/» 4- b)/6, where t c is 
expected time, a is optimistic time, m is most likely 
time and b is pessimistic time. (For a detailed discussion 
of these formulas, see Ref. 3.) This expected time, the 
weighted mean, is then used in all PERT calculations; it 
represents a probability of 50 per cent. A distinct ad- 
vantage of this system is that the engineer is able to ex- 
press his uncertainty in terms of these three estimates 
rather than having to express a more certain single time 
estimate. The three estimates also provide a means of as- 
sessing the risk being taken in performing the job. The 
throe-time-eslimate system is specifically designed for 
uncertain, nonrepetitive types of work. 

Deterministic, or single time estimating, on the other 
hand, does not utilize probability weighting. The engineer 
can make one estimate for the length of the activity 
which is the time he needs to accomplish it. The single 
time estimate has been used mainly in process industries 
and construction where it has been found valuable. CPM, 
which is a networking system employing a slight vari- 
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ation of PERT in terms and metliod of network prep- 
aration, also uses one time estimate. 

Once the time for the activities has been estimated and 
in the case of the three-time-estimate system, the expected 
time for the activity calculated, the expected length of the 
project can be calculated. Also, the expected dates for 
each event can be determined. The expected length of the 
project (the sum of the t ' s on the longest network path) is 
referred to as the earliest expected date (77;). It is calcu- 
lated by summing the expected times of the activities 
from the start through the completion of each network 
path (see Fig. 5). Once the T, : is calculated, the 77, or 
latest allowable date, is calculated by starting with a pre- 
determined date for the end event and subtracting the 
expected elapsed times, moving “backward” through the 
various network paths. The predetermined date for the 
end event might be the dale set by management or the 
date imposed by a customer. The 77, calculated for the 
first event on the network indicates the latest date the 
task(s)/projecl(s) can be started without causing the end 
event to slip beyond the predetermined target date (see 
Fig. 5). 

After both the earliest expected date (77.) and the latest 
allowable date (77) have been computed for each of the 
events, slack may be determined for each path in the net- 
work. Slack is the time difference between the earliest ex- 
pected date and latest a I lowable date: slack = 77, — 77-. 

'flic amount of time the expected date can slip before it 
equals the latest allowable date (77) can also be used as 
the definition of slack. Slack can be positive, negative, or 
zero. When the latest allowable date (77) is later than the 
earliest expected date (77), positive slack exists. Positive 
slack is “time-to-spare.” 

The longest time path or sequence of activities through 
a network is called the critical path. This path controls 
the completion date for the task(s)./projecl(s) represented 
by the network, since till other paths are shorter. Should 
the length of time for the critical path be the same as the 
established completion date for the network, there will be 
no time-to-spare. This time-to-spare relative to the estab- 
lished completion date is “slack time.” In Fig. 5, the slack 
lime for the critical pa th would be zero. (Note that until a 
schedule dale or directed date is applied to the network 
end event, the slack value of the critical path is always 
necessarily zero.) Sometimes the length of time for the 
critical path exceeds the established date tor completion. 
In this case the critical path is said to have negative slack. 
There is no time-to-sparc; in fact, a projected time slip- 
page condition beyond the established completion date 
exists. In like manner, there can be “positive slack” where 
the duration of the critical path is less than the scheduled 
time-to-perform from tire established starl-to-completion 
dates, indicating that the network activities will be com- 
pleted with time-to-spare. 

' Each series path in the network will have a slack value 
in relation to the established completion dale for the 
project. In this respect each and every scries path has a 
measurable “degree of criticality” which can be positive, 
zero, or negative. By definition, the longest time path is 
the most critical in relation to the established completion 
date and hence is called the critical path. AH other paths, 
which arc shorter than the critical path, tire therefore 
called slack paths. Two or more paths may have the same 
duration and so will have the same slack value. Should 


be two or more critical paths for the same network. 

It should be emphasized that the slack time for a sci , 
path pertains to the entire path and not to any one event 
or activity in particular. Any change in the activity time 
for any one activity in the path series will change the slack 
value for the entire path. 

In Fig. 5, the value of slack is zero for the path through 
events A, B, and E. Since this is the longest time path 
through the network, it is the critical path. Other paths 
through this network have positive slack up to three 
weeks (A, D, E). 

Scheduling 

Once the network has been prepared and the time 
estimates made, the calculations of expected time, latest 
time, slack, and the critical path reveal whether or not the 
plans are acceptable. Usually, the plans must be recon-.., 
sidered owing to the length of time they take and the 
considerations of the resources (people, equipment, and 
materials) required. The plan must be converted to a 
schedule. Scheduling is the conversion of the plan into a 
set of specific dates that govern the start and completion 
of work and involves the allocation of resources required 
to achieve the planned objectives. 

Many times, when the initial plan is completed, nega- 
tive slack will exist. This occurs because, in conforming 
with the basic rule of first laying out the network without 
regard for time, the engineer planned the job the way he 
would like to do it. The scheduling job now involves 
balancing the work and resources to achieve a schedule 
which can be met. By first examining the paths with nega- 
tive :T,ck and by reallocating resources and adjusting 
activities, the planner can draw up a work plan that is 
realistically phased with scheduled requirements. The 
activities with positive slack should be considered second 
since they provide a latitude for scheduling resources. 
Oiv. established, the schedule should not be considered 
cr,.:tg':,jle at will. It should only be changed when ob- 
jectives are changed, which essentially means that the 
plans to achieve these objectives require modification. 

Day-to-day control 

As the work progresses, there are changes that aflect the 
PERT network: slippages occur, key personnel become 
unavailable, unexpected breakthroughs are made, ac- 
tivities are accomplished faster than anticipated. This in- 
formation must be accumulated for analysis, to deter- 
mine the effect on all interrelated parts of the project, so 
that the plan can be updated as the schedule demands. 

The network can also be used during this phase (or tit 
any time) to assess the effect of contemplated changes on 
the schedule. This process, called simulation, can provide 
a quick determination of the impact of a proposed change 
in the plan. 

In engineering, as well as other areas, the network can 
(by being hung on the wall and information posted on it) 
serve as a visual reminder of the work to be done, who is 
to do it, and when it is to be done. As activities are com- 
pleted, the completion dates should be recorded on the 
network and the activity checked off. As more informa- 
tion becomes available on the expected time needed to ac- 
complish an activity, the new estimate should be written 
on the network. This day-to-day use ol the network pro- 
vides the latest information available. On a routine basis, 
new 77 and 77 calculations can be made and the effect on 


these equal paths be the Lpngcst in the network, there will 
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schedule measured. When slippages aQ’cct the schedule, an 
analysis must first be made into the cause and possible 
solution of the problem. Only then should changes be 
made in the plans and the schedule adjusted to assure 
successful completion. If the network is not updated and 
continuously used as a working tool, PERT becomes 
merely an extra exercise. The value of the technique lies 
in its use its a dynamic reflection of the work which must 
be done. As the project progresses, the network serves 
another valuable purpose — it can be used as a communi- 
cations tool. It is a basic reference document which can 
be used graphically in discussing the project with other 
engineers and management. 

One of its limitations, however, is its use as a visual aid 
in top management conferences or summary level presen- 
tations to the customer, where detailed network informa- 
tion is not required. We have found, more often than not, 
that the network must be translated onto a time base for 
presentation (by using a Gantt chart, for example). 

Task plan vs. project plan 

This article has discussed PERT in terms of the engi- 
neer’s role, whether he is working on a single task or as a 
member of a project team. If he is on a project team, the 
network he prepares is only part of the total project net- 
work plan. His network cannot be prepared in a vacuum; 
it must be prepared with the engineers responsible for 
other parts of the project. The network system depends 
upon planning of all interrelationships; interfaces between 
one engineer ana another must be shown. We have found 
that many times two or more engineers have different 
conceptions of what they are going to do for each other. 
The network points out such discrepancies because the 
plans cannot mesh. Whether or not the engineer prepares 
the network for part of a larger project or for a task for 
which he is solely responsible, the basic rules of network 
preparation are the same. 

PERT/COST estimating 

Many engineers, as they acquire experience and under- 
standing of the PERT (Time) techniques, ask “Why not 
include cost estimating?” In June 1962, the government 
(DOD and NASA) introduced PERT/COST. The princi- 
ples are relatively simple although the terminology is 
sometimes confusing. The basic principle of PERT/COST 
is that the network can be used for both time and cost 
planning. The work breakdown structure, as previously 
described, serves as (lie coupling device with cost estimat- 
ing done on a “work package” level. Thus the engineer 
would estimate his costs by time-phased work package. 

There arc also proponents of other methods, including 
those who prefer to estimate for each activity. On large 
programs, involving many labor skills and people, this 
has been found too cumbersome. In smaller applications 
it may be possible. In process industries and in the con- 
struction industry, where the application of manpower 
has a linear effect on time, they have been using a cost 
extension of CPM, where one objective is to optimize cost 
and time to determine the most applicable schedule and 
cost for the project. PERT/COST, on the other hand, is 
simply a discipline for estimating costs and collecting 
actuals versus the estimate. (To delve into the details of 
these systems in this limited article is not practical. The 
interested reader should refer to the publications listed in 
the bibliography.) 


Use of computers 

In attempting to convey a basic understanding of the 
concepts of PERT as it relates to and benefits the engi- 
neer, the application of computers in processing PERT 
has not been discussed. When PERT is applied to large 
projects, the use of a computer becomes essential in order 
that the information on a multitude of activities can be 
processed in a reasonable amount of time. Most com- 
puter manufacturers have PERT programs available and 
many companies and government agencies have prepared 
their own. In addition, there are programs available for 
producing networks using plotting or drafting machines 
tied in with the computer. 

It must be remembered that the use of the computer 
does not vary the technique; the computer is simply the 
mechanism for rapid processing of a large volume of data. 
Possibly the emphasis placed on computer usage with 
PERT has tended to overshadow the advantages to be 
gained by applying the PERT technique manually and 
has discouraged its use by engineers in the thought process 
applied to planning and controlling modest tasks. 

Conclusions 

In conclusion, it must be restated that PERT is neither 
a panacea nor solely an automated means for planning. 
PERT planning must be done competently, with an 
understanding of both the tool and the project. It can 
only be done effectively by the engineer or project engi- 
neer, however odious planning may seem to him. 

When used competently, PERT yields many advan- 
tages. It offers a plan which 'is well developed and is easy 
to communicate, showing clearly its objectives and inter- 
relationships. It is an improved method of time and cost 
measurement of tasks, aiding in improved assessment of 
accomplishment. It is a predictiv ; tool to highlight poten- 
tial problem areas. It provides the capability of examining 
alternative plans by simulating changes. 

It must be emphasized that proper employment of 
PERT as an effective working tool necessarily requires a 
full understanding of the technique and its assimilation 
by the engineer as part of his normal discipline in the 
planning and control of assigned tasks or projects. 
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